home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 5 / BBS in a Box -Volume V (BBS in a Box) (April 1992).iso / Files / Word / T-Tb / t.SUM Bugs < prev    next >
Text File  |  1988-08-17  |  2KB  |  63 lines
  1. Usenet Mac Digest     Sunday, August 14, 1988       Volume 4 : Issue 104
  2.  
  3.  
  4. From: cmoore@maddog.llnl.gov
  5. Subject: SUM bugs
  6. Date: 5 Aug 88 17:06:56 GMT
  7. Organization: Lawrence Livermore National Laboratory
  8.  
  9. I just got SUM in the mail from Symantec.  In playing with it I found
  10. two (apparent) bugs.
  11.  
  12. 1. Symantec tools refuses to directly accesr numbered
  13.    larger than 32767.  The only way to get at such sectors is to
  14.    figure out what file they are in or single step stafrom
  15.    sector number 32767.  Somebody needs to use a long integer here.
  16.  
  17. 2. HD Tuneup refuses to optimize some of my larger file (system for
  18.    instance) and gives a 'cannot optimize' error.  The manual says
  19.    that this indicates that there was not enough contous free
  20.    space to defragment the file.  This cannot be the case since
  21.    my hard drive currently has about 20Mb contiguous freee. 
  22.  
  23.  
  24. Anyone know if these are fixed in the rumored SUM update?
  25. --
  26. Christopher B. Moore
  27. cmoore@maddog.llnl.gov
  28.  
  29. Usenet Mac Digest     Saturday, July 16, 1988        Volume 4 : Issue 93
  30.  
  31. From: leonardr@uxe.cso.uiuc.edu
  32. Subject: Re: SUM
  33. Date: 13 Jul 88 16:18:00 GMT
  34.  
  35. ralph@computing-maths.cardiff.ac.uk(Ralph) writes in comp.sys.mac
  36.  
  37. >Ive just got Symantec Utilities for the Macintosh, and it looks pretty good
  38. >on the whole. However, it seems to clash badly with SFVol INIT 1.1 - when both
  39. >are in the system folder at boot up time, my Mac II crashes. Would anyone care
  40. >to comment on this?
  41. >
  42.           I have talked with the author of SFVol INIT, Ray Lau, and he is not
  43. sure yet why there is an incompatability here.  He seems to feel that
  44. the Shield INIT (which is the one what crashes, not SFVol) is making
  45. some assumptions that are not true after SFVol loads (trap adresses,
  46. maybe...)
  47.           The current work around (tested with SFVol INIT 1.5, but should work
  48. with  1.1 too.) is to change the name of SFVolINIT to Vol INIT so that
  49. it loads after Shield, and not before.  If you do this, things work fine
  50. and you have both of them running.
  51.  
  52. FLAME ON**
  53.           There seems to be a number of INIT now in the bitstream that require
  54. them to be loaded in a certain order in relation to others.  I would
  55. just like to put up this little flame to INIT writers (hey I write them
  56. too, I can flame!!) that they don't do things that they shouldn't, so
  57. that we don't have to figure out which order to load things! FLAME OFF**
  58.  
  59.  
  60.  
  61.  
  62.  
  63.